Can one of the admins verify this patch?

We should start gathering a set of requirements on what will be needed to improve in order for this PR to be accepted and placed into the core project.

My initial thoughts:

1. We need to see the dockerfile that you use as a base for the workspace.
2. Please document all of the non-standard software installed into the workspace that you requrie.
3. We may want to talk a little to @tolusha about packaging up some of the post-ws software into an agent, which is a new concept. Users will be allowed to "add an agent" to a ws, which will be software that can run inside. Maybe "pair-programming" would be the agent here.
4. Any sense of disk and memory requirements for running the system?

@rnavagamuwa @sunix - the technical team leads for Che and some of the product managers would like to get a meeting to present a demo, get some screen shots, and to discuss the longer term technology requirements necessary to get these changes committed into the system. Can we arrange a meeting for 6am pacific one day during an upcoming week? We will create a google hangout that lets us all share screens together. Can you propose a couple days that may work for you?

@TylerJewell I'm fine with any day.Will have to check with @sunix

I made a proposal for next Monday. Here is the google hangout link. I hope this can work for everyone.
https://plus.google.com/hangouts/_/codenvy.com/tjewell?hceid=dGpld2VsbEBjb2RlbnZ5LmNvbQ.im9k75jimfljt8c2g9tfl2j6bs&authuser=0

@TylerJewell is it possible for you to have this on next Tuesday? I'm okay with any day except next Monday. Sorry I couldn't mention this earlier. 😞

Yes - no problem!

Tyler Jewell | CEO | tyler@​codenvy.​com | 9​78​.8​84​.53​55

On Tue, Aug 16, 2016 at 9:43 AM, Randika Navagamuwa <
[email protected]> wrote:

@TylerJewell https://github.com/TylerJewell is it possible for you to
have this on next Tuesday? I'm okay with any day except next Monday. Sorry
I couldn't mention this earlier. 😞

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2131 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAX9CkH0hxWr6H6Y1pExPCymA5Pch1akks5qgeitgaJpZM4JkiPx
.

Does it look like this is going to get merged in any time soon?

It's hard to determine the time it takes for merge. Given the first review of the work, there are about 6 or so improvements that need to be made.

@rnavagamuwa - we are doing the merge tomorrow for the new stack / workspace / agent model into the master branch. It will take us a couple days to settle everything down. If you can then merge your changes with that branch and work with @tolusha on how to package up your work as an agent, then I think this will be the important step to take forward.

@TylerJewell sure. I'll merge the new changes and then work with @tolusha on packaging. 👍

@TylerJewell understand completely. I'm just excited to see this coming, I've been waiting for this feature since initial release. Thank you @rnavagamuwa for this pull request.

Guys, I'm going to rework this PR

• rebasing all the changesets
• make it work with 5.0.0-M1-SNAPSHOT

@rnavagamuwa could you give me push rights on your forked branch ?
@rnavagamuwa i let you know but i will probably make nasty push force

@sunix I gave you push rights 😄 I'm also working on moving code base to CHE 4.5. 👍

@sunix @rnavagamuwa is this ready for review? Or are more changes needed to bring it up to 5.x version?

@bmicklea yes this is ready for review.

@skabashnyuk who should review this one?

@bmicklea - this is not ready for review or merge. We need to have the pair plugin packaged as a non-default agent. We have published instructions on that, and asked @sunix for a meeting to discuss path to get that closed + resolved. We need to help with that migration + conversion.

Hi @sunix - any update on this pull request - it's highly anticipated! :)

Thank you @rnavagamuwa @sunix for the contribution. We have learned a lot from this submission. We have refactoring a number of communication systems to use JSON-RPC and we have a new file system watcher that would make notifications and implementation of such a system more efficient. We are going to close this PR to work on this alternative approach.

Could the alternative approach be expected as part of che later this year?

Hello,

I do not see mention of pair programming in the roadmap. Is it labelled differently or do you plan to add the item in the roadmap later on?

Also I would love to have a look on the architecture. Is it documented somehow=

It is an open source project so we update the roadmap with all epics that have been reserved or committed to by a contributor in the ecosystem.

The maintainers have agreed upon an architecture and approach but it is not added to the roadmap until someone commits to working on it with a pr. So it is open for anyone to grab right now.

It'd be super handy to have a Github issue to track for this effort. There's #4474, so that might be a good issue to track.

On another note, I also really like that #4474 doesn't specify a number of users who are collaborating together. Having one person make changes & having those changes show up on someone else's workspace immediately is 96% of what I'm looking forward to, and want for collaboration mechanisms.

So, it's possible today to have multiple users in a shared workspace with Che. You can give each user the same URL and they can work within that workspace. It's a last-write wins scenario, but their changes are made to a shared file system and the updates (eventually) appear on each others screen. There is no operational transform, however, and there is not multi-cursor editing where you can see the other person typing as they type. So the UX and behavior is not as you might expect, but there is a form of shared space capability in the product as it is designed today.

I think the engineer / community member that commits to doing the proper implementation will need to write a new specification as an epic replacing #4474. We tend not to have really good detailed specifications on a project until an engineer is full time committed to it. But the basic approach for the design of this is to make use of a number of server-side file-system watchers that we have built into our workspace agents on the server side to generate efficient events to let us build multi-cursor editing into different browsers sharing a common workspace.

I think the engineer / community member that commits to doing the proper implementation will need to write a new specification as an epic

Perhaps an existing collaborative editing spec or project might work well for Che. Some candidates:

• TogetherJS
• Gobby's Infinote Protocol
• Atom's Teletype (very limited solution atm)
• Mobwrite
• ShareJS
• ot.js